Modern telecommunication systems may incorporate Policy and Charging Control (PCC) architectures. A PCC architecture is described in 3GPP TS 23.203 V7.9.0 in respect of packet flows in an IP-CAN session established by a user equipment UE through a 3G telecommunications system. The particular architecture comprises: a Policy and Charging Rules Function (PCRF) and a Policy and Charging Enforcement Function (PCEF). The PCRF behaves as a Policy Decision Point (PDP) or Policy Server (PS), and the PCEF behaves as a Policy Enforcing Point (PEP). Whilst the PCRF can be implemented as a standalone node, the PCEF is preferably co-located within an Access Gateway (AG) such as a GPRS Gateway Support Node (GGSN) in a General Packet Radio Service (GPRS) core network. Such an architecture is illustrated schematically in FIG. 1, where BSS represents the Base Station Subsystem of a radio access network (e.g. GERAN or UTRAN). In a CDMA network, the AG may be a Packet Data Serving Node (PDSN). Related architectures are provided for 3GPP2 networks and TISPAN Next Generation Networks.
In the case of a PCEF co-located with a GGSN, the GGSN is responsible for inspecting data packets associated with data flows originating at and/or terminating in a user terminal served by the GGSN. In the case of a subscriber roaming into a “visited” network, the GGSN assigned to route data packets related to the (roaming) terminal is located in the subscriber's home network.
When a User Equipment (UE) initiates a data session, an IP address is assigned to it by an appropriate AG. The AG provides this IP address, together with, for example, an NAI, IMSI, or MSISDN, to the PS which in turn downloads into the AG a set of policy rules to be applied to the data session. When the UE communicates with a (final) Application Function (AF), the AF may provide session details to the PS. When the UE subsequently requests connectivity for the service provided by the AF, then the AG informs the PS, which downloads into the AG policy rules for the connection(s) required. In a 3GPP network, the AF may be a Proxy Call Session Control Function, P-CSCF, or another kind of application server to which the UE establishes an application communication via bearer(s) set up via IP-CAN session(s) through the AG.
FIG. 2 illustrates an architecture where the PCEF functionality is implemented on a separate physical machine. In this approach, the policy enforcement responsibilities are delegated to the GGSN or to the PCEF based on their respective roles in the network. As defined in GPRS, the GGSN is able to control PDP contexts, user attachments, etc., so the GGSN will control these types of parameters. The PCEF on the other hand is able to detect IP flows, service patterns (e.g. whether traffic relates to VoIP), etc., so it will be in charge of these types of settings.
In the split architecture of FIG. 2, the PCRF receives traffic information from the PCEF (the same traffic traverses the GGSN and the PCEF, so it is sufficient if only the PCEF reports traffic information). This traffic information may be for example aggregate traffic usage levels, or usage per user per service. The PCRF must then be able to distinguish which policy actions must be sent to the GGSN and which ones to the PCEF. As far as the PCEF is concerned, when it detects that a user bearer session has been initiated (PDP) context, it will download from the PCRF an Access Control List for the user. This list indicates services allowed or barred for the user. As already noted, policy actions include:                For the PCEF: policy actions such as service blocking, bandwidth throttling, introduction of latency, etc. In summary, actions that can be applied to an IP flow (for example, to an HTTP browsing session)        For the GGSN: policy actions that can be applied to a PDP context, and that will eventually be propagated to the radio network using standard GPRS mechanisms. For example, parameters like Traffic Handling Priority or Guaranteed Bit Rate, can be set by the PCRF and instructed to the GGSN        
A PCC service known as “Service Aware Charging and Control” (SACC) is provided by Ericsson A B (Stockholm, Sweden). This relies upon an architecture comprising, among other components, two functional entities/nodes, called “SAPC” and “SASN”. These nodes parallel the functions of, respectively, a PCRF and a PCEF. SACC allows GPRS network operators to analyze user-generated traffic, and enforce certain actions depending on many different factors, for example; type of traffic, user subscription, time of the day, etc. Actions to be taken include; block traffic, charge traffic, change Quality of Service (QoS), etc. By way of example, SACC could allow a network operator to define the conditions and actions shown in Table 1 below.
SACC includes a feature referred to as QBAL (Quality of Service Based on Aggregated Load). This feature allows an operator to control the QoS based on the aggregated traffic load, and change the QoS accordingly. Here, “aggregated traffic load” means the amount of bandwidth that is being used by a subscriber at a certain moment. For example, if a subscriber is using a Voice over IP (VoIP) service at 200 kbps, and at the same time is browsing the Internet at 100 kbps, the aggregated traffic load is 300 kbps. Of course, the aggregated traffic load can be measured for a subset of subscribers within a cell, or across an entire cell (i.e. the sum of the aggregated traffic load of the subscribers in that cell), by time of day (aggregated load for all subscriber in peak hours), etc.
Consider by way of example an operator who has network cells in urban areas and within which a lot of traffic is generated. This may give rise to corporate (business) subscribers not having available an acceptable bandwidth during business hours. A solution is for the operator to implement an “accumulator”, the role of which is to measure the bandwidth being used by all subscribers in a given cell. When a certain (predefined) bandwidth limit is reached, the QoS for the subscribers in that cell is lowered to prevent congestion. This approach may however result in a bandwidth reduction for all subscribers, regardless of the actual current usage. This can be mitigated in a number of ways, for example; lowering the QoS only to the “bronze” subscribers, but keeping the “gold” subscribers untouched; lowering the QoS only for certain services like Skype™, etc.
With reference to the co-located architecture of FIG. 1, QBAL can work either in the GGSN/PCEF locally, or in cooperation with the PCRF. The main difference is that, for the local approach, the GGSN/PCEF does not have per-subscriber control. In particular, as the PCEF does not store subscription information per subscriber, it can only apply QBAL based on certain global parameters.
Considering firstly the local approach, Table 2 below shows an example rule set based on total aggregated load per cell. The GGSN/PCEF continuously updates the third column of the table, and when a limit is reached, performs the action in the fourth column. Consider for example the cell with ID 10998-1. It is clear that this cell may well reach its aggregated load limit very soon. When the 40 Mbps limit is reached, subscribers within that cell will only be able to use HTTP browsing. Any other services (VoIP, streaming, etc) will be blocked
QBAL may also apply subscription information received by nodes (other than the GGSN/PCEF) to make traffic handling decisions. For example, a Charging Characteristics parameter may be provisioned initially per subscriber in the HLR, then sent to the SGSN, and finally sent to the GGSN. A UE includes the Charging Characteristics parameter in a PDP context activation. This parameter can be used to assign the subscriber to a certain subscriber group, e.g. Gold, Silver or Bronze. The GGSN/PCEF can then be configured to allow Gold subscribers to have a higher limit of aggregated load than Silver subscribers and so on. A suitable configuration table is included as Table 3 below. Once the GGSN/PCEF detects a new PDP context activation, it will extract the Charging Characteristics parameter, and classify the subscriber session into one of the categories in the first column. It will then start counting the traffic load and accumulating it to the counter of his/her category (third column). Once the limit set in the second column is reached, the GGSN/PCEF will take the action specified in the fourth column of the Table.
Considering now a scenario in which the GGSN/PCEF interworks with the PCRF to implement the QBAL service, control over subscriber load can be made more accurate since the PCRF can keep separate, aggregated load counters per subscriber and compare them with provisioned subscriber limits. For example, for a given subscriber, the following settings can be provisioned in the PCRF for a premium (Gold) subscriber:                Profile: Gold                    Maximum aggregated load for peak hours: 1 Mbps Load threshold exceeded: Throttle down to 800 kbps            Maximum aggregated load for VoIP: 400 kbps Load threshold exceeded: Throttle down to 300 kbps                        
According to this provisioning data, the PCRF will reduce the bandwidth available to a Gold subscriber if he exceeds 1 Mbps of traffic in peak hours, or will reduce the available VoIP bandwidth to 300 kbps if he exceeds 400 kpbs when using VoIP services. The usage of these services is reported by the GGSN/PCEF to the PCRF. The GGSN/PCEF is also responsible for enforcing the decision made by the PCRF. FIG. 3 illustrates schematically the operation of this control mechanism.
A problem arises when certain traffic conditions are detected in a visited network for roaming subscribers, i.e. subscribers for whom the visited network is not a home network. These conditions are, for example, congestion in a cell due to roaming subscribers, congestion in the whole visited network due to roaming subscribers at peak hours, etc. FIG. 4 illustrates this problem which shows a subscriber roaming in a visited network, and attached to a Base Station Subsystem that controls a cell area. Traffic is routed through the radio network towards the core network, where it will be routed onwards to the home network. Typically, the SGSN is the node in the visited network which connects to the home network, where the anchor point is the GGSN.
As will be appreciated from the previous discussion, analysis of traffic and policy enforcement occurs in the GGSN/PCEF, so, for roaming subscribers, this analysis and policy enforcement will happen in their home networks, not in the visited network. The QBAL (or other) mechanism is typically used by the network operators to avoid congestion problems within specific cells. Now, if the visited network operator wants to apply QBAL in a given cell, it can apply it to its home subscribers (the local PCRF communicating with the local GGSN/PCEF to enforce local policy), but not to roaming subscribers, since their traffic “escapes” from the visited network operator's control via the local SGSN. The visited network operator has no control over the policies applied to the roaming subscribers' traffic routed through the home GGSN, and equally the home network operator has no knowledge of local (cell) traffic levels in the visited network.
This situation may happen often in cells where roaming subscribers frequently connect: airports, convention centres, etc. If the visited network operator wants to have reliable control of the aggregated load in its cells, that operator will just control the traffic originated by its own subscribers via the local GGSN/PCEF, but this aggregated traffic may differ tremendously from reality, since roamers may be using a high bandwidth. The consequence may be that the aggregated load in certain cells becomes impossible to manage by the visited network operator. FIG. 5 illustrates this scenario in more detail.